src/hooks.server.ts (1)

11-15: Consider adding proper typing and error logging.

The as any cast loses type safety. Also, silently swallowing JWT verification errors may complicate debugging authentication issues in production.

-      const decodedPayload = jwt.verify(token, SUPABASE_JWT_SECRET, { algorithms: ['HS256'] }) as any;
+      const decodedPayload = jwt.verify(token, SUPABASE_JWT_SECRET, { algorithms: ['HS256'] }) as App.Locals['user'];
       event.locals.user = decodedPayload;
     } catch (error) {
+      console.warn('JWT verification failed:', error instanceof Error ? error.message : 'Unknown error');
       event.locals.user = null;

package.json (1)

54-54: Move @types/jsonwebtoken to devDependencies.

Type definitions are only needed at build time and shouldn't be shipped to production.

Move the dependency:

 "devDependencies": {
+  "@types/jsonwebtoken": "^9.0.10",
   "@eslint/compat": "^1.4.0",
   ...
 },
 "dependencies": {
-  "@types/jsonwebtoken": "^9.0.10",
   "@reown/appkit": "^1.8.14",

src/lib/supabase.ts (1)

17-17: Content-Type header is unnecessary for GET requests.

GET requests typically don't have a body, so Content-Type: application/json is redundant here. While harmless, it could be removed for cleanliness.

src/routes/+layout.svelte (1)

6-6: Add a comment to clarify the side-effect import.

This bare import initializes the auth store and sets up authentication checks at app load. A brief comment will clarify intent for future maintainers.

-  import '$lib/stores/auth';
+  // Initialize auth store and check authentication status on app load
+  import '$lib/stores/auth';

src/lib/auth.ts (3)

6-6: Type config parameter properly instead of using any.

The config parameter has type any, which loses type safety. Consider importing and using the proper Wagmi config type.

+import type { Config } from '@wagmi/core';
+
-export async function signInWithWallet(address: Address, config: any): Promise<string> {
+export async function signInWithWallet(address: Address, config: Config): Promise<string> {

---

42-44: Remove redundant try-catch that only re-throws.

The catch block at lines 42-44 catches the error and immediately re-throws it without any transformation or logging, which is redundant.

-  } catch (error) {
-    throw error;
-  }
+  }

---

37-41: Missing SSR guard before accessing localStorage.

Unlike getAuthToken and clearAuth, signInWithWallet doesn't check for typeof window === 'undefined' before accessing localStorage. While this function is unlikely to be called server-side, adding the guard would be consistent.

     const { token } = await response.json();
 
+    if (typeof window !== 'undefined') {
       localStorage.setItem(AUTH_TOKEN_KEY, token);
+    }
 
     return token;

src/routes/api/splits/[id]/+server.ts (1)

28-37: Extract duplicated authorization logic into a helper function.

The same authorization check pattern (fetch split, checksum address, check isCreator/isParticipant) is repeated in all four handlers. Consider extracting to a shared utility.

async function checkAuthorization(
  supabase: SupabaseClient, 
  splitId: string, 
  userAddress: string
): Promise<{ authorized: boolean; isCreator: boolean; split?: SplitData; error?: Response }> {
  const checksumUserAddress = getAddress(userAddress);
  const { data, error } = await supabase
    .from('splits')
    .select('*')
    .eq('id', splitId)
    .single();

  if (error || !data) {
    return { authorized: false, isCreator: false, error: json({ error: 'Split not found' }, { status: 404 }) };
  }

  const isCreator = data.payer_address === checksumUserAddress;
  const participants = data.participants as unknown as Participant[];
  const isParticipant = participants?.some(p => {
    try { return getAddress(p.address) === checksumUserAddress; } 
    catch { return false; }
  });

  return { authorized: isCreator || isParticipant, isCreator, split: data };
}

Also applies to: 89-98, 167-176, 216-225

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

src/routes/api/splits/[id]/+server.ts (2)

58-100: Restrict PUT updates so participants cannot change core split fields (including payer_address).

The PUT handler currently treats creators and participants the same:

• If the user is either isCreator or isParticipant, they can update all fields, including payer_address, description, totalAmount, and date.

That lets any participant reassign payer_address to themselves (or someone else), effectively taking ownership of the split and gaining creator‑level privileges (including delete), which is a serious authorization bug.

A straightforward fix is to reserve the full update for creators only and route participant‑level changes through the more specific PATCH endpoint:

-    const isCreator = splitData.payer_address === checksumUserAddress;
+    const isCreator = splitData.payer_address === checksumUserAddress;
@@
-    if (!isCreator && !isParticipant) {
-      return json({ error: 'Forbidden' }, { status: 403 });
-    }
+    if (!isCreator) {
+      return json({ error: 'Forbidden' }, { status: 403 });
+    }

If you do want participants to update some fields via PUT, introduce a role‑based whitelist and reject payloads containing forbidden keys for non‑creators rather than applying them blindly.

---

28-33: Guard against getAddress(p.address) throwing for malformed participant data.

All three participant checks:

• GET: participants?.some((p) => getAddress(p.address) === checksumUserAddress)
• PUT: same pattern on splitData.participants
• PATCH: same pattern on splitData.participants

will throw if any stored participant address is malformed, turning a data issue into a 500.

A minimal defensive pattern:

-    const isParticipant = participants?.some(
-      (p: Participant) => getAddress(p.address) === checksumUserAddress
-    );
+    const isParticipant = participants?.some((p: Participant) => {
+      try {
+        return getAddress(p.address) === checksumUserAddress;
+      } catch {
+        return false;
+      }
+    });

Apply the same change in the PUT and PATCH handlers where this check is duplicated.

According to the viem documentation, does `getAddress` throw an exception when called with an invalid Ethereum address (e.g., bad checksum or wrong format), or does it return a falsy value?

Also applies to: 92-94, 212-215

src/routes/api/splits/+server.ts (1)

10-23: Defensively handle getAddress() failures for user and payer addresses.

Both usages:

• const checksumAddress = getAddress(userAddress);
• if (getAddress(split.payerAddress) !== getAddress(userAddress)) { ... }

will throw if either userAddress (from the token) or split.payerAddress (from the request body) is malformed. Today that ends up as a generic 500 rather than a clear client error.

Consider wrapping these in a small guard and returning a 400 instead:

-    const checksumAddress = getAddress(userAddress);
+    let checksumAddress: string;
+    try {
+      checksumAddress = getAddress(userAddress);
+    } catch {
+      return json({ error: 'Invalid user address' }, { status: 400 });
+    }

and for the POST check:

-    if (getAddress(split.payerAddress) !== getAddress(userAddress)) {
+    let payerChecksum: string;
+    let userChecksum: string;
+    try {
+      payerChecksum = getAddress(split.payerAddress);
+      userChecksum = getAddress(userAddress);
+    } catch {
+      return json({ error: 'Invalid address in request' }, { status: 400 });
+    }
+
+    if (payerChecksum !== userChecksum) {
       return json({ error: 'Forbidden: can only create splits for yourself' }, { status: 403 });
     }

This keeps authorization logic while avoiding treating bad input as a server error.

In viem, what does `getAddress` do when passed an invalid or malformed Ethereum address string (e.g., wrong length or non-hex)? Does it throw an error or return a fallback?

Also applies to: 77-79

src/lib/stores/auth.ts (1)

38-64: Guard wallet‑driven auth side effects to the browser and avoid double clears.

Right now the address.subscribe side effects (calling clearAuth() and attemptSignIn) can run during SSR if the wallet store ever emits a non‑null value server‑side, and clearAuth() is invoked twice when transitioning from a real address to a falsy $address.

Consider:

• Wrapping the subscription in the same browser guard as checkAuthStatus():

-if (typeof window !== 'undefined') {
-  checkAuthStatus();
-}
-
-address.subscribe(async ($address) => {
+if (typeof window !== 'undefined') {
+  checkAuthStatus();
+
+  address.subscribe(async ($address) => {
     if (lastAddress && lastAddress !== $address) {
       clearAuth();
       isAuthenticated.set(false);
       signInError.set(null);
     }
 
     if (!$address) {
       clearAuth();
       isAuthenticated.set(false);
       signInError.set(null);
       lastAddress = null;
       return;
     }
 
     lastAddress = $address;
 
     const currentlyAuthenticated = get(isAuthenticated);
 
     if (!currentlyAuthenticated) {
       await attemptSignIn($address);
     }
-});
+  });
+}

• (Optional) Removing the first clearAuth() branch for the “address becomes falsy” case, since the !$address block already clears state.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro